Una vez que se tiene publicado el binario, para la promoción entre ambientes se puede gestionar la solicitud vía Service Now.

Promoción Ambientes Previos

1. Levanta tu Requerimiento en Service Now, aplica para las plataformas:

   • Distribuido, Citrix, EOT, Microservicios, Nube, Control M y Apps Moviles:

     • Catálogo de servicios > Servicios de Soporte > PROMOCIÓN DE CAMBIOS

   • Etiquetas de Mainframe:

     • Catálogo de servicios > Servicios de Soporte > ETIQUETAS MAINFRAME

       • Nota: el vobo de Testing únicamente aplica para promociones a PRE y este debe de venir atachado en el REQ.

2. Ingresa la información solicitada.

3. Una vez atendida la instalación/configuración, el requerimiento aparecerá con el estatus de cerrado.

Asignación de Elementos INFO\Generación de IDL´s

Para la asignación de los elementos INFO así como para la generación de las IDL ahora se realizará por medio de requerimientos de atención de Integración:

Service Catalog > Servicios de Soporte > PROMOCIÓN DE CAMBIOS > Requerimientos integración

• Para Asignación de elementos:

  • RFC/Demanda Vigente al cual se asocian los cambios.

  • Llenar todos los campos solicitados dentro del REQ.

  • Incluir el formato de Etiqueta para la asignación de los elementos.

  • Al cierre del REQ se informará si los elementos que están disponibles y la asignación con el número de etiqueta

• Para generación de IDL´s:

  • RFC Vigente para la generación de IDL´s

  • Llenar todos los campos solicitados dentro del REQ

  • Incluir el formato de generación de IDL´s

  • Para poder generar la IDL se necesita la validación del equipo Mantenimiento de centrales que esta venga atachada en el REQ.

  • Al cierre del REQ se informará la IDL generada o si está presento errores en la generación.

Una vez atendida la Asignación/Generación IDL, el requerimiento aparecerá con el estatus de cerrado.

Requerimiento Promoción de Cambios

Para la solicitud de instalación de cambios, se requiere llenar la siguiente información en el Requerimiento:

• • RFC: RFC con estatus válido, ya sea Normal o Estándar. En caso de no contar con él, notificar al equipo de integración.

  • Ambiente: Indicar en el que se requiere el despliegue. Para UAT se requiere Vo. Bo. de Testing via CDD. para etiqueta Mainframe el vobo debe de venir atachado en el REQ

  • Fecha de solicitud.

  • Descripción:

    • Liga de Nexus del artefacto a desplegar o automatizar

    • Liga del Tag de Git a la carpeta que contenga los archivos de configuración, scripts de base de datos (con su respectivo rollback), XML’s, etc.

    • Para Microservicios, agregar la liga de la documentación en swagger

    • Indicar si los archivos llevan un orden específico de instalación.

    • Para los scripts de base de datos se requiere Vo. Bo. del área de Modelado de Datos (excepto DML´s), indicar servidor, nombre proyecto nube, nombre BD e instancia .

    • Otorgar los permisos requeridos en Git para visualizar la información anterior.

    • En caso de requerir tareas de instalación especiales, agregar el archivo con las instrucciones también versionado dentro del proyecto en GIT.

NOTA: Dentro de un requerimiento se pueden especificar las tareas que sean necesarias para un cambio en el RFC (no es requisito levantar un REQ por tarea)

Aplicaciones CITRIX

• • Agregar liga de Git dónde se encuentra el Script de ejecución de instalación o archivo instalador correspondiente.

  • Servidor(es) Citrix donde se aplicará el cambio.

  • Aplicaciones Visual Basic para las que se requiere esta información:

    • AGENTEGNP

    • AUDATEX

    • CMS R17

    • AVAYA IE

    • HOD / RECALL / SSC

    • INFO

    • NUEVO EMISOR

    • NZ

    • RECIBO DUPLICADOR CONSULTA

    • SALVAMENTOS

    • SASS MEDICION

    • VIDA INVERSION

Requisitos RFC Normal

• Demanda vigente, en estatus de “Ejecución” y el Flujo Asociado “Planeado”.

• Demanda debe contener “Fecha de Liberación Valorada” >= fecha del RFC.

• Ingresar los datos obligatorios de la plantilla del RFC.

• Documentar en el campo “Bloque funcional” módulo_rfc_nombredeltema.

• APR, Nota técnica y documentos de infraestructura requeridos.

• Encontrarse en estatus de “Evaluación” cuando se solicite avance por correo.

• Asignado a Administración de Cambios.

• El RFC debe contener el campo “Solicitado para la Fecha” =< “Fecha de Liberación Valorada”.

• “Días de monitoreo” (Período de garantía, por default son 5 días).

• El RFC debe contener en la sección de "Tareas de cambio", debe contener la tarea de "Plan de ejecución" y "Plan de retorno".

• Las liberaciones quedan suspendidas 3 días previos y 3 días posteriores al cierre mensual.

Requisitos RFC Estándar

• Datos obligatorios de la plantilla del RFC.

• Encontrarse en estatus de "Evaluación".

• Asignado a integración.

• Nota técnica y documentos de infraestructura requeridos.

• Documentar en el campo “Bloque funcional” módulo_rfc_nombredeltema.

• Incidente asociado a liberación (para el caso de Período de garantía).

• El RFC debe contener en la sección de "Tareas de cambio", debe contener la tarea de "Plan de ejecución" y "Plan de retorno".

• Soporte a Usuarios no modifican código.

• Las liberaciones quedan suspendidas salvo revisión 3 días previos y 3 días posteriores al cierre mensual.

Horarios Ventanas de Instalación

Contacto: integracion.eot@gnp.com.mx

Glosario

• QA/PR1: Ambiente de aseguramiento de la calidad (Quality Assurance), es el ambiente posterior a desarrollo y anterior a UAT/PRE.

• UAT/PRE: Ambiente de Preproducción o User Acceptance Testing, posterior a QA/PR1 y anterior a producción.

• PRO: Ambiente de Producción, posterior a UAT/PRE.

• RFC: Solicitud de cambio (Request for Change) es una petición formal de Cambio en espera de ser implementada.